Cryptographic method and system

ABSTRACT

First data to be sent by a first party to a second party is encrypted using public data of a trusted party and an encryption key string formed using at least a hash value generated by hashing at least one condition that typically serves as an identifier of an intended recipient of the first data. The encrypted first data is provided to a data recipient who requests a decryption key from the trusted party. The trusted party is responsible for verifying that the recipient meets the specified conditions before providing the decryption key. A valid decryption key is only provided if the correct conditions have been supplied to the trusted party.

FIELD OF THE INVENTION

The present invention relates to cryptographic methods and system and,in particular, to data transfer methods and systems that useIdentifier-Based Encryption.

BACKGROUND OF THE INVENTION

Identifier-Based Encryption (IBE) is an emerging cryptographic schema.In this schema (see FIG. 1 of the accompanying drawings), a dataprovider 10 encrypts payload data 13 using both an encryption key string14, and public data 15 provided by a trusted authority 12. This publicdata 15 is derived by the trusted authority 12 using private data 17 anda one-way function 18. The data provider 10 then provides the encryptedpayload data <13> to a recipient 11 who decrypts it, or has itdecrypted, using a decryption key computed by the trusted authority 12based on the encryption key string and its own private data.

A feature of identifier-based encryption is that because the decryptionkey is generated from the encryption key string, its generation can bepostponed until needed for decryption.

Another feature of identifier-based encryption is that the encryptionkey string is cryptographically unconstrained and can be any kind ofstring, that is, any ordered series of bits whether derived from acharacter string, a serialized image bit map, a digitized sound signal,or any other data source. The string may be made up of more than onecomponent and may be formed by data already subject to upstreamprocessing. In order to avoid cryptographic attacks based on judiciousselection of a key string to reveal information about the encryptionprocess, as part of the encryption process the encryption key string ispassed through a one-way function (typically some sort of hash function)thereby making it impossible to choose a cryptographically-prejudicialencryption key string. In applications where defence against suchattacks is not important, it would be possible to omit this processingof the string.

Frequently, the encryption key string serves to “identify” the intendedmessage recipient and this has given rise to the use of the label“identifier-based” or “identity-based” generally for cryptographicmethods of the type under discussion. However, depending on theapplication to which such a cryptographic method is put, the string mayserve a different purpose to that of identifying the intended recipientand, indeed, may be an arbitrary string having no other purpose than toform the basis of the cryptographic processes. Accordingly, the use ofthe term “identifier-based” or “IBE” herein in relation to cryptographicmethods and systems is to be understood simply as implying that themethods and systems are based on the use of a cryptographicallyunconstrained string whether or not the string serves to identify theintended recipient. Generally, in the present specification, the term“encryption key string” or “EKS” is used rather than “identity string”or “identifier string”; the term “encryption key string” is also used inthe shortened form “encryption key” for reasons of brevity.

A number of IBE algorithms are known and FIG. 2 indicates, for threesuch algorithms, the following features, namely:

-   -   the form of the encryption parameters used, that is, the        encryption key string and the public data of the trusted        authority (TA);    -   the conversion process applied to the encryption key string to        prevent attacks based on judicious selection of this string;    -   the primary encryption computation effected;    -   the form of the encrypted output.

The three prior art IBE algorithms to which FIG. 2 relates are:

-   -   Quadratic Residuosity (QR) method as described in the paper: C.        Cocks, “An identity based encryption scheme based on quadratic        residues”, Proceedings of the 8^(th) IMA International        Conference on Cryptography and Coding, LNCS 2260, pp 360-363,        Springer-Verlag, 2001. A brief description of this form of 1 BE        is given hereinafter.    -   Bilinear Mappings p using, for example, a Tate pairing t or Weil        pairing ê. Thus, for the Weil pairing:    -   ê: G₁×G₁→G₂        where G₁ and G₂ denote two algebraic groups of prime order q and        G₂ is a subgroup of a multiplicative group of a finite field.        The Tate pairing can be similarly expressed though it is        possible for it to be of asymmetric form:    -   t: G₁×G₀→G₂        where G₀ is a further algebraic group the elements of which are        not restricted to being of order q. Generally, the elements of        the groups G₀ and G₁ are points on an elliptic curve though this        is not necessarily the case. A description of this form of IBE        method, using Weil pairings is given in the paper: D. Boneh, M.        Franklin—“Identity-based Encryption from the Weil Pairing” in        Advances in Cryptology—CRYPTO 2001, LNCS 2139, pp. 213-229,        Springer-Verlag, 2001.    -   RSA-Based methods The RSA public key cryptographic method is        well known and in its basic form is a two-party method in which        a first party generates a public/private key pair and a second        party uses the first party's public key to encrypt messages for        sending to the first party, the latter then using its private        key to decrypt the messages. A variant of the basic RSA method,        known as “mediated RSA”, requires the involvement of a security        mediator in order for a message recipient to be able to decrypt        an encrypted message. An IBE method based on mediated RSA is        described in the paper “Identity based encryption using mediated        RSA”, D. Boneh, X. Ding and G. Tsudik, 3rd Workshop on        Information Security Application, Jeju Island, Korea, Aug.,        2002.

A more detailed description of the QR method is given below withreference to the entities depicted in FIG. 1 and using the same notationas given for this method in FIG. 2. In the QR method, the trustauthority's public data 15 comprises a value N that is a product of tworandom prime numbers p and q, where the values of p and q are theprivate data 17 of the trust authority 12. The values of p and q shouldideally be in the range of 2⁵¹¹ and 2⁵¹² and should both satisfy theequation: p, q≡3 mod 4. However, p and q must not have the same value.Also provided is a hash function # which when applied to a stringreturns a value in the range 0 to N-1.

Each bit of the user's payload data 13 is then encrypted as follows:

-   -   The data provider 10 generates random numbers t₊ (where t₊ is an        integer in the range [0, 2^(N)]) until a value of t₊ is found        that satisfies the equation jacobi(t₊,N)=m′, where m′ has a        value of −1 or 1 depending on whether the corresponding bit of        the user's data is 0 or 1 respectively. (As is well known, the        jacobi function is such that where x²=−#mod N the jacobi (#,        N)=−1 if x does not exist, and =1 if x does exist). The data        provider 10 then computes the value:        S₊≡(t ₊ +K/t ₊)modN        where: s+corresponds to the encrypted value of the bit m′        concerned, and K=#(encryption key string)    -   Since K may be non-square, the data provider additionally        generates additional random numbers t (integers in the range        [0,2^(N))) until one is found that satisfies the equation        jacobi(t_, N)=m′. The data provider 10 then computes the value:        s_≡(t _(—) −K/t_)modN    -   as the encrypted value of the bit m concerned.

The encrypted values s₊ and s for each bit m′ of the user's data arethen made available to the intended recipient 11, for example via e-mailor by being placed in a electronic public area; the identity of thetrust authority 12 and the encryption key string 14 will generally alsobe made available in the same way.

The encryption key string 14 is passed to the trust authority 12 by anysuitable means; for example, the recipient 11 may pass it to the trustauthority or some other route is used-indeed, the trust authority mayhave initially provided the encryption key string. The trust authority12 determines the associated private key B by solving the equation:B²≡K modN (“positive” solution)

If a value of B does not exist, then there is a value of B that issatisfied by the equation:B²≡−KmodN (“negative” solution)

As N is a product of two prime numbers p, q it would be extremelydifficult for any one to calculate the decryption key B with onlyknowledge of the encryption key string and N. However, as the trustauthority 12 has knowledge of p and q (i.e. two prime numbers) it isrelatively straightforward for the trust authority 12 to calculate B.

Any change to the encryption key string 14 will result in a decryptionkey 16 that will not decrypt the payload data 13 correctly. Therefore,the intended recipient 11 cannot alter the encryption key string beforesupplying it to the trust authority 12.

The trust authority 12 sends the decryption key to the data recipient 11along with an indication of whether this is the “positive” or “negative”solution for B.

If the “positive” solution for the decryption key has been provided, therecipient 11 can now recover each bit m′ of the payload data 13 using:m′=jacobi(s ₊+2B,N)

If the “negative” solution for the decryption key B has been provided,the recipient 11 recovers each bit m′ using:m′=jacobi(s _(—)+2B,N)

Returning now to a general consideration of IBE encryption, oneapplication is to enable the data provider 10 to provide encryptedpayload data over an unprotected communications path for receipt anddecryption by a recipient 11 where certain conditions are met, namelycondition 1 and condition 2. To ensure that the conditions are metbefore a recipient can read the payload data 13, the conditions areplaced in the IBE encryption key string 14 and sent along with theencrypted payload data. Upon receipt, the data receiver 11 passes theencryption key string to the trusted authority 12 with a request for thecorresponding IBE decryption key 16. The trusted authority 12 onlyprovides the decryption key (over a secure channel) if satisfied thatthe conditions 1 and 2 included in the encryption key are met.Typically, the conditions serve to identify the intended recipient insome manner and can therefore be considered as the recipient'sidentifiers by the requesting data receiver 11; however, otherconditions are also possible such as a time or date condition.

The foregoing example exhibits a number of potential drawbacks. Moreparticularly, the conditions are transmitted in clear which may beundesirable particularly where the conditions are identifiers of theintended data receiver. In certain circumstances, it is better for theconditions not to be included in the encryption key but to be provide bythe data receiver to the trusted authority. However, this runs the riskof the data receiver modifying the conditions.

It is an object of the present invention to provide improvedcryptographic methods and apparatuses.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, there is provided adata-transfer method comprising:

-   -   (a) encrypting first data at a first party using as encryption        parameters both public data of a trusted party and an encryption        key string comprising a hash value generated by hashing second        data comprising at least one condition;    -   (b) providing the encrypted first data to a second party, and        the encryption key string and said at least one condition to a        trusted party;    -   (c) at the trusted party effecting both a first check that the        hash value in the encryption key string matches the result of a        hash based on the said at least one condition provided in step        (b), and a second check that the or each said at least one        condition is met; and    -   (d) providing a decryption key to the second party only if said        checks are satisfactory, this decryption key being generated at        the trusted party using the encryption key string and private        data related to said public data.

The present invention also encompasses a system for carrying out thedata transfer method of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way ofnon-limiting example, with reference to the accompanying diagrammaticdrawings, in which:

FIG. 1 is a diagram illustrating the operation of a prior art encryptionschema known as Identifier-Based Encryption;

FIG. 2 is a diagram illustrating how certain IBE operations areimplemented by three different prior art IBE methods;

FIG. 3 is a diagram of a system embodying the present invention; and

FIG. 4 is a flow chart of a process carried out by a trusted authorityof the FIG. 3 system.

BEST MODE OF CARRYING OUT THE INVENTION

FIG. 3 illustrates a system embodying the present invention, the systemcomprising a first computing entity 20 associated with a data providerparty; a second computing entity 30 associated with a data receiverparty; and a third computing entity 40 associated with a trustedauthority. The computing entities 20, 30 and 40 are typically basedaround general-purpose processors executing stored programs but mayinclude dedicated cryptographic hardware modules. The computing entities20, 30 and 40 inter-communicate as needed (see arrows 50-53) via, forexample, the internet or other network, though it is also possible thatat least some of the entities actually reside on the same computingplatform.

In the following, references to the data provider, data receiver and thetrusted authority are generally used interchangeably with references totheir respective computing entities 20, 30 and 40.

In functional terms, the data-provider entity 20 comprises acommunications module 24 for communicating with the entities 30 and 40,a control module 21 for controlling the general operation of the entity20, and a cryptographic module 22 for executing certain cryptographicfunctions comprising a hash function and an IBE encryption function.

The data-receiver entity 30 comprises a communications module 34 forcommunicating with the entities 20 and 40, a control module 31 forcontrolling the general operation of the entity 30, and a cryptographicmodule 32 for executing certain cryptographic functions comprising ahash function (the same as that used by the entity 20) and an IBEdecryption function.

The trusted authority entity 40 comprises a communications module 48 forcommunicating with the entities 20 and 30, a control module 41 forcontrolling the general operation of the entity 40, a cryptographicmodule 42 for executing certain cryptographic functions, a conditionchecking module 43, and a user registration module 44. The cryptographicmodule 42 is arranged to implement both a hash function (the same asthat used by the entity 20) and an IBE decryption function; in addition,the module 42 includes a unit 45 for generating an IBE decryption keyusing both a supplied encryption key string and private data securelyheld in local store 46.

The system employs Identifier-Based Encryption with the computingentities 20,30 and 40 having, in respect of IBE encryption/decryption,the roles of the data provider 10, data recipient 11 and trustedauthority 12 of the FIG. 1 IBE arrangement. The IBE algorithm used is,for example, the QR algorithm described above with respect to FIG. 1with the private data held in store 46 being random prime numbers p,qand the corresponding public data being number N.

Consider the situation where the data provider 20 wishes to encryptmessage data (“msg”) for sending over an unprotected communications pathfor receipt and decryption by a recipient that meets certain conditions,namely Condition 1 and Condition 2. These Conditions 1 and 2 are unknownto the data receiver 30 and the data provider 20 wishes to keepCondition 2 confidential from the data receiver 30.

It is assumed that the data provider 20 has previously registered withthe trusted authority 40 and obtained (see arrow 50) a public/privatekey pair K20 _(pubic)/K20 _(private) where K20 _(public) is simply apublic identifier of provider 20 (such as a name) and K20 _(private) isthe IBE decryption key formed by the trusted authority using the K20_(public) as an IBE encryption key and its private data p,q. The userregistration module 44 is responsible at the time of registration forensuring that the public key K20 _(public) is a correct identifier ofthe data provider 20; the module 44 is also arranged to keep a record ofcurrently valid registered users.

To encrypt the message data msg, the data provider 20 first forms an IBEencryption key string K_(ENC) comprising:

-   -   K20 _(public)    -   ::Condition 1    -   ::H(K20 _(private):: H(msg):: nonce:: Condition 1:: Condition 2)    -   :: E(K20 _(pubic), N; (H(msg):: nonce:: Condition 2))        where:    -   :: means concatenation,    -   H(x) means the hash of data x using any suitable hash function        such as SHA1,    -   E(k,n;y) means the IBE encryption of data y using encryption key        string k and the public data n of a trusted authority, and    -   a nonce is a one-time use random number selected by the data        provider 20 and provided for freshness.

The process of forming the encryption key string K_(ENC) is carried outby the cryptographic module 22 under the direction of the control module21.

As can be seen, whilst Condition 1 is visible in the encryption keystring K_(ENC), the Condition 2 only appears in encrypted form.Furthermore, the encryption key string K_(ENC) includes a hash of themessage data msg, and a hashed quantity that includes both thedata-provider's private key K20 _(private) and the message data hash; aswill be seen hereinafter, this enables the trusted authority 40 to checkthe origin of the encryption key string K_(ENC) and the integrity of themessage hash.

After the key K_(ENC) has been generated, the control module 21 causesthe cryptographic module 22 to use the key and the trusted authority'spublic data N to encrypt the message data msg. The encrypted data andthe encryption key string K_(ENC) are then made available by thecommunications module 24 to the data receiver 30 (see arrow 51).

On receiving the encrypted message data and the encryption key stringK_(ENC), the control module 31 of the data receiver 30 may, if itunderstands the structure of the encryption key string, examine theidentity K20 _(public) of the data provider 20 and the unencryptedCondition 1. If the data receiver determines that it wants to read themessage data and that it meets Condition 1, or if the data receiverdecides to proceed without checking Condition 1 (for example, because itdoes not know the structure of the encryption key string), the controlmodule 31 causes the encryption key string K_(ENC) to be sent (arrow 52)to the trusted authority 40 with a request for the correspondingdecryption key K_(DEC).

On receipt of the request from the data receiver 30 for the decryptionkey K_(DEC), the control module 41 of the trusted authority 40 overseesthe processing represented by the flow chart of FIG. 4. Moreparticularly, the control module 41 first parses (step 61) theencryption key string K_(ENC) provided with the request into its fourconstituent components (the four concatenated components listed above)—this typically being done on the basis of predetermined separatorsinserted between the concatenated components.

Next, the control module 41 passes the component formed by the dataprovider's public key K20 _(public) to the module 44 in order todetermine whether the data provider 20 is still a valid registered userof the services of the trusted authority 40 (step 62). If this checkfails, a negative response is returned to the requesting data receiver30 (step 72) and processing terminates; otherwise processing proceeds.In fact, the trusted authority 40 may decide to skip this check andsimply proceed directly to the following processing steps.

The next processing step (step 63) involves the control module 41passing the Condition 1 component extracted from the encryption keystring K_(ENC) to the condition checking module 43 for it to determinewhether the data receiver 30 satisfies this condition. Conditionchecking may involve the consultation of internal and/or externaldatabases and/or the interrogation of the data receiver 30 (for whichpurpose the latter may be implemented on a trusted computing platform).If this check fails, a negative response is returned to the requestingdata receiver 30 (step 72) and processing terminates; otherwiseprocessing proceeds.

The following step (step 64) involves the control module 41 obtainingthe data provider's private key K20 _(private) Whilst this key couldhave been stored in the user registration module 44 and retrievedagainst the data provider's public key K20 _(public) (as extracted fromthe encryption key string K_(ENC)), it is simpler to have the keygeneration unit 45 regenerate the K20 _(private) using the dataprovider's public key K20 _(public) and the private data p,q held instorage 46.

Once the private key K20 _(private) has been obtained, it is used (step65) to decrypt the encrypted component of the encryption key stringK_(ENC) in order to reveal:

-   -   H(msg):: nonce:: Condition 2        this expression thereafter being separated into its three        constituent elements.

Next, the control module 41 passes the now-decrypted Condition 2 to thecondition checking module 43 for it to determine whether the datareceiver 30 satisfies this condition (step 66). If this check fails, anegative response is returned to the requesting data receiver 30 (step72) and processing terminates; otherwise processing proceeds.

Following the successful check of Condition 2, the control module 41causes the hash:

-   -   H(K20 _(private):: H(msg):: nonce:: Condition 1:: Condition 2)        to be recomputed (step 67) using the key K20 _(private) obtained        in step 64, the values of H(msg), the nonce and Condition 2        obtained by the decryption in step 65 of the encrypted data        contained in K_(ENC), and the Condition 1 obtained in step 61        from parsing K_(ENC). This re-computed hash value is then        compared (step 68) with the corresponding component contained in        the encryption K_(ENC). If these hash values are different then        clearly something is wrong and a negative response is returned        to the requesting data receiver 30 (step 72) and processing        terminates.

However, if the hash values match, the trusted authority 40 accepts thatthe data provider is the entity associated with the private key K20_(private) and thus with the public key K20 _(public); the trustedauthority also accepts that the message hash H(msg) is reliable. Thecontrol module 41 now causes the key generation unit 45 to compute (step69) the decryption key K_(DEC) using the encryption key string K_(ENC)and the private data p,q. Finally, the trusted authority 40 returns(step 70) the decryption key K_(DEC) together with H(msg) to the datareceiver 30 (see arrow 53, FIG. 3).

It will be appreciated that the ordering of the checking steps 62, 63,66 and 68 relative to each other and to the other steps of the FIG. 4 isnot critical (subject to the items concerned having become available)save that the steps 62, 63, 66 and 68 need to be carried out before thedecryption key K_(DEC) is sent to the data receiver in step 70.

On receiving the decryption key K_(DEC) the data receiver 30 uses it todecrypt the encrypted message data after which it computes the hash ofthe message and compares it with that received from the trustedauthority 40 as a final check on the message integrity. The datareceiver 30 now has the integrity-checked decrypted message and can besure that the trusted authority 40 is happy that the data provider 20 isas identified by the public key K20 _(public) included in clear in theencryption key string K_(ENC).

In the foregoing process, the only additional burden placed on the datareceiver 30 is the message integrity check involving forming a hash ofthe message and comparing it with the message hash supplied by thetrusted authority 40; otherwise, the functioning of the data receiver 30is exactly as for any basic IBE system with the data receiver 30 passingthe encryption key string K_(ENC) to the trusted authority 40 andreceiving back the decryption key K_(DEC). If the data receiver isprepared to pass the encrypted message to the trusted authority, theneven the message integrity check can be carried out by the trustedauthority.

The process described above with respect to FIGS. 2 and 3 not onlyprovides the advantages of data-provider authentication carried out bythe trusted authority 40, and a check on the integrity of the messagehash, but also enables the data provider 20 to include a hiddencondition (Condition 2 in the example) in the encryption key stringK_(ENC) only visible to the trusted authority 40 and not to the datareceiver 30. Whilst the data provider 20 must, of course, know how toform the multi-component encryption key string K_(ENC), the datareceiver 30 need know nothing of the structure of this key, it beingrelieved of this burden by the trusted authority 40. Placing all theprovider authentication and message integrity components into theencryption key string K_(ENC) intimately ties these components to theencrypted message data.

Many variants are possible to the above-described embodiment. Forexample, instead of the QR IBE method being used for the encrypting anddecrypting the message data msg, other, analogous, cryptographic methodscan be used such as IBE methods based on Weil or Tate pairings.Furthermore, the data K_(ENC) may be subject to further predeterminedprocessing (such as a further hash) before being used in the operativeencryption process and in this case the trusted authority will need touse the same processed value of K_(ENC) when generating K_(DEC) (itwill, however, be appreciated that the trusted authority will need toreceive K_(ENC) unprocessed in order for it to be able to access theindividual components of K_(ENC)). These generalizations also apply tothe variants discussed below.

In the above-described embodiment, the data provider's public key K20_(public) is used in clear in the encryption key string K_(ENC) toidentify the data provider and to encrypt the encrypted component of theencryption key string K_(ENC), whilst the corresponding private key K20_(private) is used as an authenticator of the identity of the dataprovider by its inclusion in the hashed component of the encryption keystring K_(ENC). Although in the above embodiment this public/private keypair K20 _(public)/K20 _(private) is an IBE encryption/decryption keypair, this need not be the case and the public/private key pair could,for example, be an RSA public/private key pair. In this case, theprivate key used to authenticate the data provider 20 cannot be computedin step 64 and must be accessed by look up in a database kept by theuser registration module 44 relating private key to the data-provideridentifier, such as the public key, included in clear in the encryptionkey string K_(ENC). A potential drawback of using an RSA public/privatekey pair is that if the public key is used as the in-clear data-provideridentifier included in the encryption key string K_(ENC), the real-worldidentity of the data provider may not be apparent to the data receiverand will generally need translation. In fact, the in-clear data-provideridentifier included in the encryption key string K_(ENC) need not be thepublic key of the public/private key pair (whether IBE or RSA based) butcan be any valid identity for the data provider that is known andaccepted by the trusted authority as corresponding to the private key itholds for the data provider 20.

It is also possible to use a symmetric key known only to the dataprovider and the trusted authority to form the encrypted component ofthe encryption key string K_(ENC) and for inclusion in the hashedcomponent in place of K20 _(private). In this case, the in-clearidentifier of the data provider that is included in the encryption keystring K_(ENC) would not, of course, be this key but would be anidentifier known by the trusted authority as associated with the dataprovider and thus with the symmetric key concerned.

It may be noted that the key used for encrypting the encrypted componentof the encryption key string K_(ENC) need not be cryptographicallyrelated to the key used in the hashed component of K_(ENC)—all that isrequired is that the key used for encrypting the encrypted component ofthe encryption key string K_(ENC) is confidential to the data provider20 and the trusted authority 40 and is known by the latter to belong tothe same party as the key used in the hashed component of the keyK_(ENC).

It may also be noted that where there are only a few users registeredwith the trusted authority, it would be possible to omit the firstcomponent K20 _(public) (or other in-clear identifier of the dataprovider 20) and simply arrange for the trusted authority 40 to try outthe keys/key pairs of all registered users to see if the message camefrom a registered user. If a key/key pair was found that both sensiblydecrypted the encrypted component of K_(ENC) and gave rise to a computedhash matching the hashed component of K_(ENC), the identity of the dataprovider can be considered as established and can be passed to the datareceiver if the latter needed to know this identity.

As already indicated, the form of encryption key string K_(ENC)described above with reference to FIGS. 2 and 3 serves at least threepurposes besides encryption of the message data msg; more particularly,it provides for passing a condition in confidence to the trustedauthority, for authentication of the data provider to the trustedauthority, and for the transmission and checking of message integritydata (the message hash). However, where only one or two of thesefunctions is required, the form of the encryption key string K_(ENC) canbe simplified.

Considering first the authentication of the data provider, this isachieved by including in the encryption key string K_(ENC) a hash of ashared secret known to the data provider 20 and the trusted authority40; in the illustrated embodiment this shared secret is the private keyK20 _(private) but, as discussed, could be an RSA private key of thedata provider or a symmetric key, or indeed any shared secret. Thepresence in the encryption key string of the Conditions 1 and 2 is notrelevant to this data-provider authentication function so that theexample encryption key string K_(ENC) given above can be reduced to:

-   -   K20 _(public)    -   :: H(K20 _(private):: H(msg):: nonce)    -   E(K20 _(public), N; (H(msg):: nonce))

As already noted, where there are only a few users registered with thetrusted authority, the first component K20 _(public) can be omitted.Furthermore, the nonce could be omitted from both the encrypted andhashed components of K_(ENC) provided freshness was not required.However, retention of the message hash H(msg) in both the hashedcomponent and the encrypted (or, alternatively, in the in-clear)component of K_(ENC) is necessary where it is desired to retain a linkbetween the originator identity established for the encryption keyK_(ENC) and a message encrypted with this key—removal of the messagehash H(msg) would enable the encryption key string K_(ENC) to be used bya third party for encrypting a message which might then appear to comefrom the data provider 20 in view of the latter's identity beingembedded in the encryption key string K_(ENC). In fact, it is possibleto envisage circumstances where the original of the encryption keystring K_(ENC) is of a significance independent of the origin of amessage encrypted with that key. For example, where the encryption keystring K_(ENC) includes one or more conditions in clear and/or in theencrypted component, then these may represent standard terms andconditions of a party which wishes to establish this fact independentlyof any message encrypted with the encryption key string; in this case,the conditions (or a hash of the conditions) would need to be includedin the hashed component of the encryption key string to enable a checkon their integrity. Where only non confidential conditions wereinvolved, such as Condition 1, then the encryption key string K_(ENC)would be of the form:

-   -   K20 _(public)    -   ::Condition 1    -   ::H(K20 _(private):: nonce:: Condition 1)    -   ::E(K20 _(public), N; nonce)

If the nonce is not required, then the encrypted component can beomitted. The condition or conditions included in such an encryption keycan be replaced, or supplemented, by other data not intended to be anidentifier of the data receiver 30 such as data about the data provider20. This other data can, like the conditions, be included in clearand/or in the encrypted component and should also be included, directlyor after hashing, in the hashed component if it is to be linked to theoriginator identity established for the encryption key string K_(ENC).

Rather than using an un-keyed hash function such as SHA1, it is possibleto use a keyed hash such as HMAC with the private key K20 _(private) (orother shared secret) being the hash key used for hashing the otherelement or concatenated elements of the hashed component. In this case,the trusted authority would use the same keyed hash function in seekingto compute a hash value matching that in the encryption key stringK_(ENC).

If the identity of the data provider is not an issue, then theencryption key string K_(ENC) of the illustrated embodiment reduces to:

-   -   K20 _(public)    -   ::Condition 1    -   H(H(msg):: nonce:: Condition 1:: Condition 2)    -   ::E(K20 _(public), N; (H(msg):: nonce:: Condition 2))        leaving only the elements forming the identifiers of the data        receiver (Conditions 1 and 2) and those concerned with the        message integrity (the in-clear component K20 _(public) is        retained to facilitate the trusted authority obtaining the key        K20 _(private) for decrypting the encrypted component, though as        already discussed, in appropriate circumstances the component        K20 _(public) can be omitted). If only message integrity is of        interest (for example, if there are no conditions), then the        hashed component of this reduced form of the encryption key        string K_(ENC) can be removed leaving:    -   K20 _(public)    -   :: E(K20 _(public), N; (H(msg):: nonce))

In fact, since K20 _(pubic) is public, encrypting the message hash doesnot serve much purpose as anyone wishing to provide a substitute messagefor that originally sent can also change the message hash and encrypt itaccordingly. However, if the message hash, with or without the additionof a nonce, is encrypted using a private key (whether of apublic/private key pair or a secret symmetric key) the message hash isprotected from change and serves its purpose of providing a messageintegrity check for the original message. Rather than using the privatekey to encrypt the message hash, it can be used to form a keyed hash,such as HMAC, of the message. The trusted authority can be arranged todetermine the correct private key to use for checking either by trialand error through a limited set of such keys, or by the inclusion in theencryption key string K_(ENC) of a suitable indicator in clear.

Whether the message hash is included in a protected form or another form(such as in clear or encrypted with a public key) in the encryption keystring K_(ENC), its inclusion permits detection of non malicious changesin the encrypted message such as may result from problems in thecommunications path. At its simplest, inclusion of the message hash, inclear or in a derived form, into the encryption key string K_(ENC)provides a link between the encryption key string and the message givingrise to the included hash value. Whilst this does have utility withoutthe addition of further data into the encryption key string, it isprimarily of interest for associating such further data included in thekey K_(ENC) with the message, this further data being, for example,identity information of the data provider and/or data receiver as hasalready described.

As regards the inclusion in the encryption key string K_(ENC) ofconditions serving to identify the data receiver, it will be appreciatedthat the number of in-clear and encrypted conditions can be varied fromthat described above for the illustrated embodiment. Thus, there may benone, one or more in-clear conditions and none, one or more encryptedconditions, in any combination. Furthermore, where the conditions arealready known to the data receiver 30, the conditions need not beincluded as such in the encryption key string K_(ENC) but they shouldstill included in the hashed component to enable the trusted authorityto confirm that the conditions passed to it by the data receivercorrespond to those intended by the data provider and included in thehashed component. In this case, for the illustrated embodiment, theencryption key string K_(ENC) reduces to:

-   -   K20 _(public)    -   ::H(K20 _(private):: H(msg):: nonce:: Condition 1)    -   ::E(K20 _(public), N; (H(msg):: nonce))        there being no Condition 2 as this example only involves        conditions known to the data receiver. If the data-provider        identity information and message hash data are not required and        the nonce is omitted, the encryption key string K_(ENC) further        reduces to:    -   H(Condition 1)

This is of value because it ensures that the data receiver can only readthe encrypted message data supplied by the data provider if it presents,and satisfies, the correct condition 1 to the trusted authority. Thedata receiver cannot alter the hash value to match a different conditionas this would result in a decryption key K_(DEC) that would not serve todecrypt the received encrypted message data.

It may be noted that it is possible to achieve a similar result to thatof the foregoing paragraph without using an IBE schema for theencryption and decryption keys K_(ENC), K_(DEC). Consider a situationwhere the trusted authority has a secret key K_(T) which it uses togenerate a secret key K_(P) for the data provider 20 (the subscript “p”here standing for the data Provider):

-   -   K_(P)=HMAC(K_(T), identifier of data provider)

This enables the data provider 20 to generate a symmetric key K_(PR):

-   -   K_(PR)=HMAC(K_(P), identifier of data receiver)        where the identifier of the data receiver is the Condition 1.        The key K_(PR) is then used with a symmetric encryption        algorithm to encrypt the message data which the data provider        then sends, along with its identifier, to the data receiver. In        order for the data receiver to obtain the key K_(PR) for        decrypting the message data, it must provide its identifier        (Condition 1) and that of the data provider to the trusted        authority who can now compute the key K_(PR) as it already knows        K_(P) or can re-compute it; assuming that the data receiver        meets the Condition 1, the trusted authority then returns the        key K_(PR) to the data receiver to enable the latter to decrypt        the encrypted message data. If the data receiver supplies a        modified Condition 1, the resultant key will not decrypt the        encrypted message data. By also sending a hash of the key        K_(PR), the data provider can provide assurance to the trusted        authority that K_(PR) has been created by the data provider.

With regard to the above-described reduced forms of the encryption keystring K_(ENC), it will be understood by persons skilled in the art thatthe FIG. 4 process carried out by the trusted authority is appropriatelymodified to omit any unnecessary computation or checks and to effect anychanges needed to take account of the changed form of the encryption keystring K_(ENC).

It will also be understood by persons skilled in the art that whereelements are concatenated before being operated upon by a hashing orencryption function, the order of concatenation can be varied from thatdescribed above provided that the ordering is used consistently (forexample, the trusted authority 40, when computing the hash value in step67 of FIG. 4, must use the same ordering of the concatenated elements asused by the data provider 20 when generating the encryption key stringK_(ENC)). Indeed, elements can be combined in ways other than byconcatenation. Thus, the concatenation operations performed by the dataprovider 20 that must be reversed by the trusted authority 40 can bereplaced by any reversible combination function, whilst theconcatenation operation performed by the data provider 20 in combiningthe elements for the hashed component:

-   -   H(K20 _(private):: H(msg):: nonce:: Condition 1:: Condition 2)        (or any simplified version discussed above) can be replaced by        any deterministic combination function (the trusted authority        needing only to be able to repeat the combination, not reverse        it). Of course, the trusted authority and data provider must        know to use the same combination functions.

1. A data-transfer method comprising: (a) encrypting first data at afirst party using as encryption parameters both public data of a trustedparty and an encryption key string comprising a hash value generated byhashing second data comprising at least one condition; (b) providing theencrypted first data to a second party, and the encryption key stringand said at least one condition to a trusted party; (c) at the trustedparty effecting both a first check that the hash value in the encryptionkey string matches the result of a hash based on the said at least onecondition provided in step (b), and a second check that the or each saidat least one condition is met; and (d) providing a decryption key to thesecond party only if said checks are satisfactory, this decryption keybeing generated at the trusted party using the encryption key string andprivate data related to said public data.
 2. A method according to claim1, wherein in step (b) the encryption key string is provided to thetrusted party via the second party.
 3. A method according to claim 1,wherein in step (b) said at least one condition is provided to thetrusted party by the second party.
 4. A method according to claim 1,wherein in step (a) said second data comprises at least one furtherelement in addition to said at least one condition; the first checkcarried out in step (c) checking that the hash value in the encryptionkey string matches the result of a hash of a combination of said atleast one further element and the said at least one condition providedin step (b),.
 5. A method according to claim 1, wherein the encryptionprocess effected using said encryption key and the public data of thetrusted party is an identifier-based cryptographic process utilisingquadratic residuosity.
 6. A method according to claim 1, wherein theencryption process effected using said encryption key and the publicdata of the trusted party is an identifier-based cryptographic processutilising Weil or Tate pairings.
 7. A data-transfer system for theencrypted transfer of first data, the system comprising: data providerequipment comprising: a hashing arrangement for generating a hash valueby hashing second data comprising at least one condition; akeystring-forming arrangement for forming an encryption key string usingat least said hash value; an encryption arrangement for encrypting thefirst data using as encryption parameters both public data of a trustedparty and said encryption key string; and an output arrangement foroutputting at least the encrypted first data and the encryption keystring; data receiver equipment for receiving the encrypted first dataoutput by the data provider equipment; and trusted party equipmentassociated with said trusted party and comprising: an input arrangementfor receiving the encryption key string and said at least one condition;a first checking arrangement for carrying out a first check that thehash value in the encryption key string matches the result of a hashbased on the said at least one condition; a second checking arrangementfor carrying out a second check that the or each said at least onecondition is met; and a decryption-key providing arrangement forproviding a decryption key to the data receiver equipment only if saidchecks are satisfactory, the decryption-key providing arrangement beingarranged to generate this decryption key using the encryption key stringand private data related to said public data.
 8. A system according toclaim 7, wherein the data receiver equipment is arranged to receive theencryption key string from the data provider equipment and forward it tothe trusted party equipment.
 9. A system according to claim 7, whereinthe data receiver equipment is arranged to provide said at least onecondition to the trusted party equipment.
 10. A system according toclaim 7, wherein said second data comprises at least one further elementin addition to said at least one condition; the first checkingarrangement being arranged to check that the hash value in theencryption key string matches the result of a hash of a combination ofsaid at least one further element and the said at least one condition.11. A system according to claim 7, wherein the encryption arrangement isarranged to encrypt the first data, using said encryption key string andthe public data of the trusted party, in accordance with anidentifier-based cryptographic process utilising quadratic residuosity.12. A system according to claim 7, wherein the encryption arrangement isarranged to encrypt the first data, using said encryption key string andthe public data of the trusted party, in accordance with anidentifier-based cryptographic process utilising Weil or Tate pairings.